Method for optimising the distribution of a service from a source to a plurality of clients in a network

ABSTRACT

This method for determining locations of service instances for optimising distribution of a service in a network, from a source to a plurality of clients each having predetermined requirements, wherein the network can be modelled by means of a graph, comprises steps of: placing a service instance in each leaf in the graph; and, starting from the leaves, for each service instance: checking whether the service instance when placed in a vertex on the next higher level can fulfil the requirements of all clients to be served by said service instance; and moving or not the service instance one level higher, depending on the result of the checking step.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.10/725,714, filed Dec. 2, 2003, pending, which claims the benefit of EPApplication No. 02293038-2, filed Dec. 9, 2002, now U.S. Pat. No.1,437,874, the disclosure of which is incorporated herein by reference.

BRIEF SUMMARY OF THE INVENTION

The present invention relates to a method for optimising thedistribution of service instances for providing a service from a sourceto a plurality of clients in a network. A service instance is an entitythat can provide a service to a client. In the case of Internetservices, the service instance is for example a proxy server; in thecase of information services, the service instance is for example adatabase; in the case of logistics, the service instance can be atransfer station. In a telecommunications network, the “clients” may befor example access networks or access nodes or user terminals.

The invention is described here, by way of non-limiting example, in itsapplication to a telecommunications network of the WAN (Wide AreaNetwork) type, for Point-To-Multipoint (PTM) service distribution.However, it can be applied in a number of other domains, such aslogistics, traffic management, etc.

Depending on the topology of the network, the placing of serviceinstances may be rather complex.

In a distributed system wherein services are accessed simultaneously bymultiple, geographically distributed clients, an optimal servicedistribution strategy should consider many factors, depending on therequirements of a variety of terminals and sub-networks. It should alsoconsider the service requirements. In addition, an optimal strategyshould limit the number of service instances (i.e. equipment or serviceitems providing the service to the clients), while providing adequateservice quality to all clients. However, there is currently nowell-defined solution for such PTM scenarios.

The present invention aims at overcoming this drawback.

To this end, the present invention provides a method for determininglocations of service instances for optimising distribution of a servicein a network, from a source to a plurality of clients each havingpredetermined requirements, wherein the network can be modelled by meansof a graph, the method being remarkable in that it comprises steps of:

placing a service instance in each leaf in the graph; and

starting from the leaves, for each service instance:

checking whether the service instance when placed in a vertex on thenext higher level can fulfil the requirements of all clients to beserved by this service instance; and

moving or not this service instance one level higher, depending on theresult of the checking step.

According to a particular feature, the method further comprises thesteps of determining that at least two service instances meet in theabove-mentioned vertex and combining these service instances.

Thus, thanks to the present invention, the minimum number of serviceinstances necessary to provide the service to the clients in a networkas well as the corresponding locations of these service instances can bedetermined.

According to a particular feature, the method further comprises a step,prior to the placing step, of determining levels in the graph.

Thus, if the graph modelling the network does not comprise levels perse, this step makes it possible to build a levelled structure of thegraph.

The checking step may comprise a table-based analysis step, or a Petrinet analysis step.

With the same object as that mentioned above, the present invention alsoprovides a vertex in a graph modelling a network, remarkable in that itimplements a method as succinctly described above.

With the same object as that mentioned above, the present invention alsoprovides a server in a telecommunications network, remarkable in that itis a source implementing a method as succinctly described above.

With the same object as that mentioned above, the present invention alsoprovides a device for determining locations of service instances foroptimising distribution of a service in a network, from a source to aplurality of clients each having predetermined requirements, wherein thenetwork can be modelled by means of a graph, this device beingremarkable in that it comprises:

a lodging unit, for hosting a service instance;

a checking unit, for checking whether the service instance when placedin a vertex on the next higher level can fulfil the requirements of allclients to be served by this service instance;

a processing unit, for coordinating the lodging unit and the checkingunit and for controlling the vertex; and

an input/output unit, for sending and receiving messages and serviceinstances.

According to a particular feature, the device further comprises acombining unit, for determining that at least two service instances meetin the vertex and for combining these service instances.

With the same object as that mentioned above, the present invention alsoprovides a vertex in a graph modelling a network, remarkable in that itcomprises a device as succinctly described above.

The advantages of the vertices, of the server and of the device aresimilar to those of the method according to the present invention andare therefore not repeated here.

Other features and advantages of the present invention will appear uponreading the following detailed description of preferred embodiments,given by way of non-limiting examples.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

The description refers to the accompanying drawings, in which:

FIG. 1 illustrates schematically a network wherein two intersecting setsof sub-networks for providing a service respectively from a server totwo clients are identified, wherein the sets of sub-networks containthose sub-networks that can provide the service with adequate servicequality;

FIG. 2 illustrates schematically the complexity of the servicedistribution topology in the case of a higher number of clients;

FIG. 3 shows an example of a service distribution tree;

FIGS. 4 a, 4 b, 4 c, 4 d are flow diagrams showing successive steps ofan optimisation method in accordance with the present invention, invarious embodiments wherein the network is modelled by means of atree-based topology;

FIG. 5 is a flow diagram showing successive steps of an optimisationmethod in accordance with the present invention, in another embodimentwherein the network is modelled by means of a meshed topology;

FIG. 6 is a non-limiting example of a table illustrating the analysiscarried out for a vertex in the graph modelling the network, in thecourse of the optimisation method according to the invention in aparticular embodiment; and

FIG. 7 illustrates schematically a device according to the presentinvention, in a particular embodiment.

DETAILED DESCRIPTION OF THE INVENTION

In the following, there is considered a telecommunications network ofthe WAN type.

A service is to be distributed from a source, such as a server, to aplurality of clients in the network.

Before applying the optimisation method according to the invention, anumber of preconditions to be fulfilled may optionally be defined. Byway of non-limiting example, it may be required that the maximum numberof service instances does not exceed a predetermined percentage (e.g.25%) of the actual number of clients that are being served. Moreover, itmay be required that the delay associated with the distribution of theservice to each client does not exceed a predetermined value (e.g. 500ns, or any other value specified by the service).

It is assumed that the network can be modelled by means of a graph, forexample by using a tree-based topology (in which case the graph is atree) or a partially or fully meshed topology, both well known from aperson skilled in the art.

The “destination points” in the graph are the sub-networks that areconnected to the clients (i.e. the leaves in the tree). The destinationpoints know, for example from conventional routing protocols, such asBGP (Border Gateway Protocol), the distance to the server that initiallyprovides the service.

According to the present invention, the maximum distance allowed betweenthe service instances and the destination points is determined on thebasis of predefined metrics.

“Network metric” has the meaning of a function d(X,Y) defined on theCartesian square of a given set, e.g. a set of network nodes, satisfyinga number of standard properties: d is non-negative, it satisfies atriangle property, d(X,Z)≦d(X,Y)+d(X,Z), and d(X,X)=0 for any nodes X,Y, Z. To define a metric in a network, it is sufficient to define thelength of each connection between two nodes in the network. Given anumber of metrics d1, d2, . . . , dk defining the distances betweenarbitrary nodes X, Y in the network, it is possible to reduce thesemetrics into a single, combined metric d(X,Y) by using existingprocedures well known from a person skilled in the art, for example bytaking the maximum of d1, d2, . . . , dk or their sum or even theirconvolution with a given weight, depending on the subscriber or customerrequirements, the costs, etc.

A typical example of metrics is related to the quality of service, suchas bandwidth, delay, jitter, reliability, security, response time RTT(Round Trip Time) or a combination of these factors. The required metricor a corresponding required minimum and/or maximum value is determinedby the destination points (e.g. the clients in case of serviceprovisioning), the source (e.g. a service), the network provider, theservice provider or any combination of these entities.

Therefore, depending on the context, the term “metric” may have eitherthe meaning of a representation of a certain network, of a connection ora link, or the meaning of a representation of distance in graph theory,or more generally in metric spaces theory.

A destination point in the graph may represent either a single entity,such as a client terminal or an access network, or a collection ofentities, such as all clients in an access network, all clients in aspecific area, all clients with the same characteristics, all customersof a specific logistics service, etc. It is to be noted that the clientsmay be connected to the destination points in an indirect manner, e.g.via a sub-network that is not modelled in the graph.

As shown in FIG. 1, several networks or sub-networks (seven intersectingnetworks in FIG. 1) between the server and client(s) may be used to hostservice instances. The (sub-)networks, depicted by labels Si, i=1, . . ., 32 on the drawing, are not necessarily on a single path between theserver and the client(s).

In the case of a single client, it is possible to determine allsurrounding (sub-)networks where a service instance would enableadequate service quality provisioning, i.e. would fulfil the client'srequirements. Such an analysis can be based on distance vector routingprotocols that use a table with the shortest paths to all destinations,i.e. (sub-)networks. The result of such an analysis step would be atable per client (or per access network) indicating all the(sub-)networks that can host service instances and provide adequateservice quality. This table can then be sorted on path distance from theclient(s) to the corresponding (sub-)networks, where each (sub-)networkis represented only once in the table (per client). The path distance isdetermined by any of the metrics or metrics combinations mentionedabove.

However, in a partially or fully meshed topology, many paths generallyexist between the client(s) and server and hence, the above-mentionedtables will contain many (sub-)networks. Therefore, in the case of amulticlient service distribution situation, an optimisation step isrequired in order to determine, out of the possible (sub-)networks perclient, the (sub-)networks for service distribution with the minimumnumber of service instances. FIG. 1 shows that for both clients C1 andC2, the sets of (sub-)networks that provide adequate service qualityhave been identified. The (sub-)networks S10, S13, S14, S21, S28 and S29are part of the intersection between the two networks and can carry outservice provisioning for both clients. Although it is possible in thisscenario to identify an optimal (sub-)network from the intersection, theproblem becomes complex when several thousands of clients are involvedand that an optimal service distribution must be determined for manyintersections of many clients, such as in the case of a plurality ofintersecting sets of (sub-)networks, as illustrated in FIG. 2.Furthermore, adding or removing clients may affect a significant part ofthe service distribution topology.

Therefore, a simplified topology representation is needed. A deliverytree structure can be used in order to optimise the topology andminimise the number of required service instances. Since the servicedistribution has a single source and multiple clients, the delivery treecan be created, by way of non-limiting example, by the Reverse PathMulticast (RPM) algorithm described by Hersent et al. in “IP Telephony:Packet-based multimedia communications systems”, Addison-Wesley, Harlow,2000.

As known from a person skilled in the art, the RPM algorithm buildssource-based trees that span (sub-)networks with clients. Other deliverytrees, such as minimum cost spanning trees or Steiner trees, can also beapplied.

The RPM distribution tree algorithm creates a tree of (sub-)networkswith exactly one shortest path from the server to all clients/accessnetworks. Since there is a unique path from the server to each accessnetwork, loops are impossible.

Each path from the server will end in one access network.

Thus, the access networks are leaves in the service distribution tree.

FIG. 3 shows an example of a service distribution tree. Such a tree canbe based e.g. on the RPM algorithm. The service network/the server isthe root of the tree and the access networks are its leaves.

Distributing a service from the service network to S6 restricts theservice instances to be placed in one of the (sub-)networks on the pathS1, S2, S3, S4, S5, S6. Distributing a service from the service networkto S21 implies that the service instances be placed in a (sub-)networkon the path S1, S15, S16, S20, S21.

Different service requirements can be handled via a single tree built onthe basis of a combination of metrics for these given requirements.

Different service distribution algorithms according to the inventionexist, depending on the topology of the network (tree-based or meshed),the type of processing (central or distributed) and the triggering mode,i.e. the mode of starting the analysis leading to the optimisation.

The processing is either done in a central unit (e.g. the source, whichis for example the location of the server), or distributed in thedifferent nodes (e.g. where the sub-networks are located).

The triggering, i.e. the start of the analyses in the central unit or inthe different nodes is either done by a central unit, level by level, oris node-implicit, i.e. the different nodes perform an independentprocessing and merely trigger the next node (which, as will be seenlater, is a higher level node) by sending a service instance there.

Thus, there are at least four possible embodiments of the optimisationmethod according to the invention:

-   -   a service distribution optimisation procedure with a tree-based        topology, a distributed processing and a central triggering;    -   a service distribution optimisation procedure with a tree-based        topology, a distributed processing and a node-implicit        triggering;    -   a service distribution optimisation procedure with a tree-based        topology, a central processing and a central triggering; and    -   a service distribution optimisation procedure with a meshed        topology, a central processing and a central triggering.

According to the invention, it is wished to minimise the number ofservice instances. During the steps described below, the placement ofservice instances is semi-permanent, since, optionally, an additionalprocedure can be applied in order to try to move the service instancescloser to the clients without the need to replicating the serviceinstances. During this optional procedure, the service instances can beplaced in other nodes. Of course, this can only be done when the serviceinstance is moved towards the clients on a non-diverging path.

Depending on the chosen strategy, it may be decided to place serviceinstances, not closer to the clients, but closer to the source. Theinvention applies of course to both cases.

For carrying out the procedure of moving the service instances closer tothe clients, there are two options:

-   -   either the last level at which two service instances have been        merged is remembered for each service instance, and the service        instance is moved down, i.e. closer to the clients, until that        level is reached;    -   or a node knows how many branches it has, and the service        instance is moved down as long as a node has only one branch        leading to the clients (i.e. until the service instance would        have to be replicated when moving down any further).

Let us first consider the case of a service distribution optimisationprocedure with a tree-based topology, a distributed processing and acentral triggering. This embodiment is shown in FIG. 4 a.

First, a tree topology of the network is established, for example byusing a conventional routing protocol (step 40 a). Either a singlemetric or metric combinations are used. In case of a metric combination,it can be advantageous to combine different metrics into a singleoverall metric, e.g. by means of weighing.

Next, service instances are placed in all leaves of the tree (step 42a). For determining the leaves, either the source (or root) of the treeknows the leaves from the routing protocol information, or a serviceinstance is broadcast through the tree and the leaves are those pointsthat keep the service instance (instead of transmitting it). Serviceinstances may be representatives of a real service instance (e.g. via amobile agent, which is a software module), or the service instanceitself may be used. Leaves may have different distances to the root,i.e. leaves may be located at different levels in the tree.

As an option (not shown), it is then checked whether there is a serviceinstance in a node before applying the trigger to that node. Otherwise,the trigger is sent to all nodes on the corresponding level (step 44 a),e.g. the trigger is broadcast and each node checks whether it is on therequested level in the tree (e.g. each node increments a level counterand broadcasts the message to all its child nodes). The root may alsoknow the nodes for a given level from the routing protocol information.

If there is more than one service instance in the same node (test 46 a),they are merged. This means that the service instances are treated as asingle service instance.

Thus, the new single service instance has to take into account allrequirements of all the clients that are now served by the new singleservice instance. This can be implemented for example by selecting thelowest or respectively highest value for each metric that is requestedby any of the clients. This merging procedure may be carried out at theend of the global loop, which is performed upon triggering of a givenlevel. As a simpler variant, all requirements from all clients arecombined but not merged.

Next, the necessary information is fetched from the next higher levelnode, if any (step 50 a).

If, on the basis of this fetched information, i.e. consideringsimultaneously the characteristics of the next higher level node and theclient, service, etc., requirements, it is possible to move the serviceinstance to the next higher level node (test 52 a), then the serviceinstance is moved to the next higher level node (step 54 a). Otherwise,this means that the service instance cannot be moved higher and theservice instance is given a semi-permanent status (step 56 a). Thisinformation is transmitted to the root.

The global loop ends when all service instances have received asemi-permanent status (test 58 a).

Afterwards, optionally, as explained above, the procedure for moving theservice instances closer to the clients (not shown) is carried out.

If clients are removed or new clients are added, the procedure isreiterated for all nodes, unless nodes remember for which branches theyare responsible, which clients they serve and correspondingrestrictions.

Let us now describe a recursive variant of this procedure. We assumethat the leaves are aware of the requirements and restrictions put onthe service instance by clients that should be provided with theservice. This embodiment is illustrated by FIG. 4 b.

The recursive procedure uses two messages, namely a request message anda response message.

A node sends a request message to the adjacent nodes within the nextlower level in the tree (i.e. to its children nodes). If a leaf, that isa node directly connected to at least one client, is reached, a serviceinstance is created.

In a further embodiment of the invention, service instances are placedat the leaves before the sending of a request message.

In both embodiments, a leaf performs the steps of:

1. receive a request message

2. check whether the service instance can be placed at the parent node;

-   -   if so, a positive reply, comprising the requirements of the at        least one client, is sent;    -   if not, a negative reply is sent and the service instance is        given a semi-permanent status.

It is to be noted that a request message can carry information about thecharacteristics of the parent node and the link needed for checkingwhether or not a service instance can be moved into the node from thelevel below.

The response message carries service instances and the relatedinformation, e.g. requirements on the service quality and otherrestrictions. A negative response may also be sent, meaning that noservice instance will be moved up from the child node.

As mentioned above, the tree topology is established and assumed to beknown. For instance, based on routing protocol information, when a givennode receives a request message, it automatically deduces therefrom thatthe node that originated the request message is its parent, and that thereceiving node is a parent node for remaining adjacent nodes which arethen considered to be its children nodes.

According to the recursive procedure, the following steps are performed.

1. In order to start the execution of the procedure, the server sendsrequest messages to its children nodes (step 40 b).

2. Each node waits for a request message from its parent node.

3. When a request message is received from the parent node, the nodesends a request message to all its children (step 42 b).

4. After the request messages are sent, the node waits for responsemessages from all its children.

5. If all the response messages are negative (test 44 b), the node sendsa negative response to its parent upwards, and does not place anyservice instance in it (step 46 b).

6. Otherwise, if at least one positive response is received, the nodemerges the service instances received from its children and builds thecumulative requirements and restrictions for the new service instanceobtained by merging (step 48 b). As a simpler variant, all requirementsfrom all clients are combined but not merged.

7. Afterwards, the node checks whether the new service instance can bemoved upwards (test 50 b). If so, the node sends a positive responsewith the service instance characteristics (step 52 b). Otherwise, anegative response is sent and a semi-permanent status is assigned to theservice instance in the node (step 54 b).

8. The execution of this procedure stops when the server receivesresponse messages from all its children nodes (test 56 b). In case of atleast one positive response message, a service instance with asemi-permanent status is placed in the server.

9. Optionally, the service instances having a semi-permanent status canbe moved closer to the clients, as mentioned above.

With slight modifications, this recursive procedure will work in adynamic approach, when new clients are added or clients are deleted. Forthis purpose, each node shall keep its last response message and thelast response messages it received from its children. Then, upon arrivalof a response message, the node is able to re-evaluate thecharacteristics of the service instance and send a new response messageto its parent node if needed. Therefore, in a dynamic framework, nodesshould not wait until all the response messages are received from theirchildren. Each node should answer the message received from its parentafter a predetermined timer expires. The timer will have to be adjustedproperly in order to avoid too frequent re-evaluation of the serviceinstance in the node and too many new responses. It is to be noted thata timer may also be used in the procedure described above, carried outin a non-dynamic framework. The timer value can be determined from thepath distances, which information is available for example from therouting protocols.

Let us now consider the case of a service distribution optimisationprocedure with a tree-based topology, a distributed processing and anode-implicit triggering. This embodiment is illustrated by FIG. 4 c.

Like in the previous cases, a tree topology of the network is firstestablished and service instances are placed in all leaves of the tree(steps 40 c, 42 c).

A loop is then performed for each service instance. If there are otherservice instances in the node, they are merged (test 44 c, step 46 c).As well as in the previous embodiments, as a simpler variant, allrequirements from all clients are combined but not merged. The necessaryinformation is then fetched from the next higher level node, if any(step 48 c). If it is possible to move the service instance to the nexthigher level node (test 50 c), the service instance is moved to the nexthigher level node (step 52 c) and optionally, a footprint, e.g. apointer, is left in the lower level node, indicating that the serviceinstance passed the corresponding node previously. If it is not possibleto move the service instance to the next higher level node, the serviceinstance is given a semi-permanent status (step 54 c).

Optionally, if there is a footprint in the node, a corresponding messageis sent towards the root. A higher level node that receives this message(on its way to the root) checks whether it meets the requirements ofclients that can be served by the sender of the message. If yes, itremoves said requirements and calculates new cumulative requirements forthe remaining clients.

The loop stops when all service instances have been assigned asemi-permanent status (test 56 c).

Afterwards, optionally, the service instances having a semi-permanentstatus can be moved closer to the clients, as mentioned above.

In this scenario, a node may know its level in the tree from the routingprotocol information. This amounts to follow a level by level approach,as in the previous case (tree-based topology, distributed processing,central triggering) but without a central control and triggering unit.

As mentioned above, instead of the corresponding service instancerequirements, each node can store a footprint corresponding to theservice instance when that service instance has passed this nodepreviously. When another service instance arrives in that node, it canretrieve all necessary information from the footprinted serviceinstance. A footprint may also be used to optimise the procedure: a nodeonly sends a message upwards (i.e. towards the root) when a newsemi-permanent service instance is to be placed in the node and thatnode has a footprint. When a higher level node removes the serviceinstance (because a lower level node has placed the service instance),all footprints between the higher level node and the node where theservice instance is now placed have to be removed. Additionally, thehigher level node informs the lower level node that hosts the serviceinstance for the clients served previously by the node, about theclients served and their requirements. Thus, each service instance isaware of the clients and their requirements on service instancecapabilities.

This procedure can also handle removals and additions of clientsdynamically. For the new clients, a service instance is placed in thecorresponding leaf node. The service instance is then moved towards theroot according to the procedure described previously. For removedclients, a message is sent upwards, faking that a service instance forthat client has been placed at a lower level. The higher level node withthe service instance that was serving this client then removes thecorresponding requirements for the removed client.

Let us now consider the case of a service distribution optimisationprocedure with a tree-based topology, a central processing and a centraltriggering.

This procedure is not shown in the drawings since it is essentially thesame as the procedure that is carried out in the case of a tree-basedtopology, a distributed processing and a central triggering (illustratedby FIG. 4 a). The only difference is that no triggers are needed.Further optimisations are possible, due to the fact that all therequired information is centrally available.

It is to be noted that a combination of central processing anddistributed information retrieval (wherein the root or server retrievesinformation by means of queries from the different nodes) would behandled by the same procedure.

The flow diagram of FIG. 4 d summarises the succession of steps carriedout according to the optimisation method which is the subject-matter ofthe invention, in a first preferred embodiment where the network ismodelled by means of a tree-based topology.

Before the optional procedure (not shown), consisting of trying to movethe service instances closer to the clients, is carried out, theoptimisation method according to the invention is performed as shown inFIG. 4 d.

During a first step 40, a service instance is placed in each leaf of thetree.

Next, starting from the leaves in the tree (level N) and moving towardsthe root (level 0), as shown by the initialisation step 41 and thedecrementation step 46, level by level in the tree, the followingprocedure is carried out:

For each vertex of the examined level where a service instance isplaced, it is checked (test 42) whether the service instance can bemoved further up towards the root of the tree, provided the root is notreached yet (a test 47 follows the decrementation step 46 and consistsin checking whether the index representing the level is equal to 0).

In order to know whether the service instance is allowed to be movedhigher up in the tree, the vertex can contact the next vertex higher upin the tree, e.g. the corresponding resource manager in case of asub-network, in order to request the resource status. The request can beeither a general request, or a dedicated request for the correspondingrelevant metrics.

As a variant, the vertex may use resource information received fromhigher levels in the tree without sending any request.

Thus, it is checked whether the service instance placed in the vertexfulfils the requirements of all clients.

If the result of test 42 is positive, the service instance is moved tolevel i-1 (step 43). Otherwise, the location of the service instance isleft unchanged.

The two following steps 44 and 45 consist in considering the possibilityof combining several service instances with each other, and consideringtheir possible cumulative or combined requirements, respectively. Step45 is optional.

For example, during step 44, whenever two or more service instances meetin the same vertex, they are advantageously combined into one singleservice instance and the corresponding metric value describing arequirement is either the minimum or the maximum value of the metric ofthe cumulative requirement, depending on the type of metric. Forexample, if the metric represents a delay, the single metric associatedwith the cumulative requirement is the minimum of both former metrics,whereas if the metric represents the bandwidth, the metric valueassociated with the cumulative requirement is the maximum of both formermetrics. As a result of the combination of service instances, a singlecombined service instance then provides the service to multiple clientssimultaneously. As a simpler variant, all requirements from all clientsare combined, but not merged.

During step 45, in case different metrics or combinations of metrics areused for the individual branches of the tree, they are advantageouslycombined into a bigger set of metrics. For example, in case one of thebranches of the graph uses only a metric based on delay, whereas anotherbranch uses only a metric based on the bandwidth, the combining vertexmay use both the delay and the bandwidth for both branches or it may useeach metric individually for each of the branches. For example, for avideo streaming service, the combination of metrics may include apredetermined maximum delay, a predetermined minimum bandwidth and apredetermined minimum jitter (i.e. maximum delay variation) to ensure anacceptable quality of service.

In another preferred embodiment, the network may be modelled, not by atree-based topology, but by a meshed topology.

Let us consider the case of a service distribution optimisationprocedure with a meshed topology, a central processing and a centraltriggering. The procedure is as follows.

1. A network metric is built based on given requirements and constraintson delay, etc.

2. A levelled structure of the network is built, so that the first levelconsists of the server, whereas other levels consist of the nodes beingat the same distance from the server. Clients can be in any level,except the first one. The levels are ordered according to their distancefrom the server (the larger the distance, the higher the level number).

3. A set C of all clients that need to be provided with the service isbuilt.

4. Each network node is marked as being able to serve a client in casethe existing constraints allow the client to be served by a serviceinstance placed within that node of the network. Thus, one and the samenode can be marked with several potential clients.

5. The level with the highest number, that is to say the level mostdistant from the server, is selected.

6. A set S of so-called “forbidden” clients is built, which are clientsthat may be served by the given level but which cannot be served by anyservice instances if placed closer to the server.

7. If the set S is empty, the following step is step 11 below.

8. The node N of the given level which may serve at least one forbiddenclient and at the same time serve the maximal number of clients issearched and a service instance with a semi-permanent status is placedin that node.

9. All clients that may be served by the node N are removed from thesets S and C (the removed clients are disregarded at further steps).

10. If the set S is not empty, the following step is step 8.

11. The procedure stops when the set C of clients is empty or all levelshave been considered.

12. The level which is next to the level that has just been consideredand closer to the server node is selected, and the following step isstep 6.

Step 8, which is a so-called “greedy” step, since it does notnecessarily deliver an optimal result, can be modified as appropriate,depending on the network and existing requirements. For example, it mayconsist in searching the node N of the given level which may serve themaximal number of forbidden clients and in placing a service instancethere.

The complexity of the proposed procedure may vary, depending oneffectiveness of implementation, and especially on data structures usedfor network representation. In order to increase efficiency,modifications of the procedure can be considered; for example, steps 2,3, 4 can be performed dynamically to the required extent at step 6.

Afterwards, optionally, the service instances having a semi-permanentstatus can be moved closer to the clients, as mentioned above.

The flow diagram of FIG. 5 summarises the succession of steps carriedout according to the optimisation method which is the subject-matter ofthe invention, in such a preferred embodiment.

As shown in FIG. 5, a preliminary step 50 consists of building acombined network metric based on given requirements and constraints onquality of service and other characteristics, that a service instanceshall fulfil.

A levelled structure of the network is built using the combined metric,pursuant to step 2 described previously. This may be done by using aconventional routing protocol, which is aware of shortest paths towardsnetwork nodes and their length.

The next steps 52, 53, 54, 55, 56, 57, 58 are similar to steps 40, 41,42, 43, 44, 46, 47, respectively, of the embodiment of FIG. 4 d andtheir description is not repeated here.

In such a meshed topology, as well as in the case of a tree-basedtopology, the destination points in the graph are the sources where theservice instances start their way towards the service provider. Thedifferent destination points in the graph may be at different distancesfrom the service provider, i.e. the numbers of sub-networks between eachof the destination points and the service provider may be different.

Since the address of the service provider is known, the standard routingtables of the routing protocol implemented in the network can be used todetermine the next hop to reach the service provider.

Either the characteristics of all networks are available, e.g. in atable, or the characteristics of the next sub-network must be fetchedwhen it is known which sub-network is the next one on the way towardsthe service provider. The selection of the next sub-network is based onthe routing metric, which uses for instance delay as the routingcriterion. Since multiple metrics may have to be consideredsimultaneously, either for one client, or in the case of a cumulativemetric for multiple clients, the routing protocols have to be extendedto route data on the basis of multiple metrics simultaneously, unlessthe multiple metrics are combined into a single metric, as previouslydescribed.

For ensuring that different service instances be combined, serviceinstances can leave an indication, which is called a “footprint”, ineach of the sub-networks that they passed on their way towards theservice provider, so that these indications can be used by serviceinstances that arrive in the same sub-network during a later analysisstep. It makes it possible to trace the corresponding service instanceand to combine several service instances.

The indication left in each sub-network in which the service instancemoved may be a pointer to that sub-network. In this case, when moving toa new sub-network, the service instance may possibly update allpointers. However, pointers are either direct (i.e. they point to thesub-network with the service instance) or indirect (i.e. they point to asub-network which is the next one on the way to the sub-network with theservice instance). Only in the first case, all pointers have to beupdated. Therefore, no path traversal and checking is required in eachnode, since the final address is known.

As a variant, in a sub-network in which the service instance moves, itmay leave, in addition to the pointer, all required information, such asthe cumulative values of the metrics from the leaf to that sub-network,as well as, optionally, the time at which the service instance passesthrough the sub-network.

A variant for combining service instances can be based on distancevector routing protocols that contain a table with the shortest paths toall destinations. Multiple tables are required in order to reflectdifferent metrics or combinations thereof, unless the multiple metricsare combined into a single metric, as previously described. Exteriorgateway routing protocols, such as the Border Gateway Protocol (BGP),contain such tables and are used for ensuring connectivity betweensub-networks or autonomous systems. Thus, each sub-network knows itsdistance to the root, i.e. the service provider.

The sub-networks then exchange information in order to determine whichsub-network should move its service instance higher up in the tree.Similar mechanisms, such as the selection of a master, e.g. as appliedin many of the routing protocols or server selection procedures in LANs,can be applied to determine the sub-network that can start moving itsservice instance to the next higher sub-network. Taking into account themetric-based distances, the resulting master can be the one that isfurthest away from the service origin entity.

The analysis implementation can be based either on a table as depictedin FIG. 6, or on Petri nets, where the prerequisites are the conditionsand the service instances are the tokens in the network.

The table of FIG. 6 may be stored in the vertex that is carrying out theanalysis. It shows the ranges for the different clients C1 to C7. Fromthe level in the tree (mentioned in the right-most column of the table)and the corresponding range for a specific client, the sub-network Si(i=1, . . . , 23) that is the closest to the root and can provideadequate service quality to that specific client is known. In the shownexample, the highest level in the tree is 1 (the root of the tree issub-network S1) and the lowest level (the leaves of the tree) is 6. Forexample, the sub-network S2 fulfils the requirements of clients C1 andC2. It is to be noted that the prerequisites, i.e. the conditions, mayreflect cumulative requirements.

The analysis starts by checking all level 6 sub-networks, to determinewhether the service instances placed at this level are allowed to bemoved higher up in the tree. If yes, the service instances concerned aremoved one level higher and a marking is inserted in the table, forindicating that a service instance has reached that higher levelsub-network.

In addition, the corresponding metrics are considered and possiblycombined with the metrics from other service instances, coming fromother branches.

After all level 6 sub-networks have been checked, all level 5sub-networks are checked in an identical fashion, and so on.

Several parameters and additional indicators can optionally be includedin the table above in order to refine or to speed up the analysis. Forexample, as shown in the last row of the table, an indication may begiven as to the number of intersecting sub-networks per client.Intermediate analysis results may be stored in the table to speed up theprocess.

As a variant, instead of a table-based analysis, a Petri net analysiscan be used.

Petri nets are a graphical formalism for systems specification. They areformed from a finite set of places, a finite set of transitions and afinite set of arrows connecting either places to transitions ortransitions to places. Graphically, places are usually represented bycircles and transitions by bars.

A Petri net is given a state by marking its places. A marking of a Petrinet consists of assigning a non-negative integer to each place. This isusually represented graphically by inserting a number of tokens in everyplace of the net.

A transition may have one or more input and output places. If an arrowgoes from a place to a transition, the place is said to be one of thetransition's output places. A transition is said to be enabled if thereis at least one token in each of the input places. An enabled transitionmay fire. This means that one token is removed from each input place andone token is inserted in each output place of the transition. If morethan one transition is enabled, the model is non-deterministic, in thesense that given an initial marking, different evolutions of the Petrinet are possible.

In a Petri net, a transition usually models an event or action, and itsfiring represents the occurrence of the event or execution of theaction. Thus, a transition is enabled if the conditions are satisfiedthat allow the occurrence of the modelled event or action. The presenceof a token in a place may denote the existence of some condition. Forinstance, a place may model a resource, and the existence of one or moretokens in that place means the availability of one or more instances ofthat resource. For a more detailed description of the basic principlesof Petri nets, reference can usefully be made to “Fundamentals ofSoftware Engineering”, by Ghezzi et al., Prentice Hall International,New Jersey, 1991.

According to the invention, the distribution tree is modelled by a Petrinet with the same shape. The sub-networks are the places, the serviceinstances are the tokens that carry the corresponding metrics valuesalong and the transitions have associated conditions that are related tothe maximum distance that the service instance is allowed to be awayfrom the clients, i.e. from the leaves. This distance can be based onany of the corresponding metrics or combination of metrics that isimportant for the clients. Each sub-network is reflected by a place inthe Petri net. A service placement in a specific sub-network (i.e. avertex in the distribution tree or in the meshed topology) is modelledby a token in a place in the Petri net.

Tokens are first placed in the leaf places. Moving the service instancetowards the root is done by moving the tokens up through the Petri net.In order to move a token from one place to the next, a transition mustbe enabled and must fire. The firing of a transition is done by the samealgorithm as above. To this end, the token will have values that areused and updated by the analyses.

The merging of service instances is done by having transitions with lessoutput tokens than input tokens.

The final distribution of the service instances is reached when thePetri net stops to evolve, i.e. when the tokens do not move and mergeany more.

Petri nets can be applied to both the tree-based and meshed topologies.

Scheduling policies can also be used. When the pure non-determinism ofthe Petri net model is not adequate, we face the problem of specifying apolicy for selecting a transition to fire among all the enabledtransitions. A fairly simple way to solve this problem is to attachpriorities to transitions. Then the firing rule is modified as follows:if, in some state, several transitions are enabled, only the ones withmaximum priority are actually allowed to fire.

Priorities are usually defined statically. If tokens carry a value,however, dynamic priorities may be defined, whose values depend on thevalues of the tokens of the input places of the transitions.

Timed Petri nets can be used as well. Timed Petri nets are Petri nets inwhich a pair (tmin, tmax) is associated with each transition. Again,such values could be constant or computed as functions of the values oftokens at the input places. Once a transition is enabled, it must waitfor at least a time tmin to elapse before it can fire. Also, if enabled,it must fire before a time tmax has elapsed, unless it is disabled bythe firing of another transition before tmax. A timed Petri net isequivalent to an original Petri net if, for every transition, tmin=0 andtmax=indefinite.

As shown in FIG. 7, a device for determining locations of serviceinstances for optimising distribution of a service in a network, from asource to a plurality of clients each having predetermined requirements,wherein the network can be modelled by means of a graph, according tothe invention, comprises:

a lodging means 70, for hosting a service instance,

a checking unit 72, for checking whether the service instance whenplaced in a vertex on the next higher level can fulfil the requirementsof all clients to be served by this service instance, as describedpreviously,

a processing unit 74, for coordinating the lodging unit 70 and thechecking unit 72 and for controlling the vertex, and

an input/output unit 76, for sending and receiving messages and serviceinstances.

In the particular embodiment illustrated in FIG. 7, the device furthercomprises a combining unit 78, for determining that at least two serviceinstances meet in the vertex and for combining these service instances,as described previously.

1. A method, in a network, of optimizing the distribution of a servicefrom a source to a plurality of client terminals in a network, themethod comprising: defining preconditions for providing the service tothe plurality of client terminals; determining requirements of both theplurality of client terminals and one or more sub-networks through whichthe plurality of client terminals are connected to the source;graphically modelling locations in the network for one or more serviceinstances with respect to the one or more sub-networks that areconnected between the source and the plurality of client terminals;determining a maximum distance allowed between the service instances andthe plurality of client terminals using predefined metrics; andaccording to the determined requirements and the determined maximumdistance, minimizing the one or more service instances that areproviding the service to the plurality of client terminals.
 2. Themethod according to claim 1, wherein the determining a maximum distanceallowed step further comprises, determining whether the one or moreservice instances can fulfil the requirements of the plurality of clientterminals.
 3. The method according to claim 1, wherein the step ofgraphically modelling locations further comprises determining levels ina graph produced by said graphic modelling.
 4. The method according toclaim 1, further comprising determining that at least two serviceinstances are located less than the maximum distance and combining saidservice instances.
 5. The method according to claim 1, wherein thedetermining a maximum distance allowed step further comprises atable-based analysis step.
 6. The method of claim 5, wherein saidchecking step comprises a Petri net analysis step.
 7. A device in atelecommunications network, for optimizing the distribution of aservice, from a source, to a plurality of client terminals in a network,the method comprising means for determining preconditions for providingthe service to one or more client terminals in the plurality of clientterminals means for determining requirements of both the plurality ofclient terminals and one or more sub-networks through which the one ormore client terminals are connected to the one or more sources;modelling means for graphically modelling locations in the network forone or more service instances with respect to the one or moresub-networks that are connected between the source and the one or moreclient terminals; a lodging unit for hosting the one or more serviceinstances; a checking unit for checking whether the one or more serviceinstances, when located in the graphically modelled locations, canfulfil the requirements of the one or more client terminals; aprocessing unit, for coordinating the lodging unit and the checking unitand for controlling a vertex in the graphic model of the locations; andminimizing the one or more service instances that are providing theservice to the plurality of client terminals.
 8. The device according toclaim 7, further comprising; a combining unit, for determining that atleast two service instances meet in the vertex and for combining the atleast two service instances.
 9. The device according to claim 7, whereinthe modelling means determines a maximum distance allowed between theone or more service instances and the one or more client terminals andstill fulfil the requirements of the plurality of client terminals. 10.The device according to claim 9, further comprising means fordetermining that at least two service instances are located less thanthe maximum distance and combining said service instances.
 11. Thedevice according to 7, wherein the modelling means for graphicallydetermining locations, further comprises means for determining levels ina graph produced by said graphic modelling.
 12. The device according toclaim 11, wherein the modelling means further comprises a table-basedanalysis means for determining levels.
 13. The device according to claim11, wherein the modelling means further comprises a Petri net analysismeans for determining levels.